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ABSTRACT: The Adam language is an extension of Ada that supports 
multiway activities, which are cooperative activities involving two or more 
processes. This support is provided by three new constructs: diva proce- 
dures, meet statements, and multiway accept statements. Diva procedures 
are recursive generic procedures having a particular restrictive syntax that 
facilitates translation for parallel computers. Meet statements and multi- 
way accept statements provide two ways to express a multiway rendezvous, 
which is an n-way rendezvous generalizing Ada’s 2-way rendezvous. While 
meet statements tend to have simpler rules than multiway accept state- 
ments, the latter approach is a more straightforward extension of Ada. 
The only nonnull statements permitted within meet statements and mul- 
tiway accept statements are calls on instantiated diva procedures. A call 
on an instantiated diva procedure is also permitted outside a multiway 
rendezvous; thus sequential Adam programs using diva procedures can be 
written. Adam programs are translated into Ada programs appropriate for 
use on parallel computers. 
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Chapter 1 

Overview 


After a brief motivation and a general description of Adam, this chapter 
describes three kinds of applications for which Adam is more suitable than 
Ada. The chapter also gives simple examples of Adam programs to illus- 
trate the new language concepts, describes the target computers supported 
by the prototype translator, and discusses the relationship between Adam 
and Ada. 


1.1 Motivation for Adam 

Managers within large companies specify projects at a high-level, more 
in terms of what should be accomplished than in terms of precisely how 
everyone involved should do all necessary actions to accomplish the project. 
Assistants then refine any necessary details. Imagine what it would be like 
to manage thousands of employees for a company whose policy requires 
managers — without assistance — to describe projects directly in terms 
of the interactions between all pairs of workers on the project. Absurd 
as it may seem, Ada programmers must abide by a similar policy, since 
parallel communication in Ada must be expressed at the level of the two-way 
rendezvous. Even in the common situation where each worker is asked to 
execute the same code — the Single Program Multiple Data programming 
model — deciding who does what when can swamp the programmer with 
low-level detail. 

The Adam language permits programmers to express algorithms either 
at a high-level of machine-independent parallelism involving cooperative, 
multiway activities, or at an even higher level in which multiway activities 
are completely implicit. The Adam translator then produces a semanti- 



cally equivalent Ada program, with the required activities automatically 
converted down to the much lower level of two-way rendezvous. The name 
“Adam” derives from Ada plus support for multiway activities. 

Effective computing requires adequate support from both hardware and 
software. The hardware support for high-speed computing is expected to 
be increasingly in the form of heterogeneous computing systems[22], sys- 
tems that provide access to a variety of supercomputers and to workstation 
clusters. The lack of adequate software support for parallel computers has 
been termed the “parallel software crisis” [23] . In the long-run, ideal system 
software for heterogeneous computing systems should be capable of auto- 
matically shipping a program or program module to the most appropriate 
resource in the system for processing. The Adam language is a step in this 
direction. As explained later in the chapter, the prototype Adam trans- 
lator generates three different kinds of target code, and for each of three 
different kinds of parallel computers there exist Adam programs for which 
the target code would achieve some form of asymptotically optimal perfor- 
mance. Moreover, the characteristics of these Adam programs that make 
them appropriate for a particular kind of parallel computer are typically 
known prior to run-time, assuming the desired number of processes and the 
length of certain vectors is known prior to run time. 


1.2 General Description of Adam 

Except for trivial restrictions on identifiers, Adam is an extension of Ada 
[26]. Thus all applications supported in Ada are also supported in Adam. 
In addition, Adam supports data parallel applications more conveniently 
than Ada, especially applications involving the kind of cooperative work 
described in this chapter. 

Two related kinds of cooperative multiway activities are supported by 
Adam: the diva call and the multiway rendezvous. 

• The diva call is a call on a high-level generic procedure that has 
a particular restrictive syntax, employs no explicit parallelism, uses 
recursion in a significant way, and whose correctness can be proven 
using strong induction. The name “diva” derives from the divide- 
and-conquer mechanism used by such calls. A diva call is useful for 
such applications as assigning values to the components of vectors and 
summarizing information concerning one or more vectors having the 
same length. Diva calls can be placed in an Adam program anywhere 
a procedure call is permitted in Ada, after the instantiation of its 
generic procedure. 
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• The multiway rendezvous generalizes the Ada two-way rendezvous 
by specifying that two or more tasks are synchronized during the ex- 
ecution of a (possibly empty) block of code. The simplest way to 
express a multiway rendezvous in Adam is using a meet statement 
in the task body of an array of tasks. When all members of the 
array reach the meet statement, the block of code is executed, af- 
ter which the members resume their independent execution. Local 
variables of the participating tasks can be accessed within the meet 
statement, so a meet statement can resemble a meeting of the par- 
ticipating tasks. While the meet statement is sufficient for writing 
a multiway rendezvous, the Adam language also provides a second 
way to express a multiway rendezvous, the multiway accept, which 
is a straightforward generalization of the Ada accept. The multiway 
accept historically preceded the meet statement and has supported 
programming experiments comparing the two alternate approaches. 

The diva call and the multiway rendezvous are integrated within the Adam 
language: diva calls are the only non-null statements that can be nested 
within the two Adam constructs supporting the multiway rendezvous. The 
block of code within a multiway rendezvous describes work to be performed 
during the multiway rendezvous and, since the tasks participating in the 
multiway rendezvous are synchronized during this work, this work is per- 
formed — logically speaking — by one or more additional agents. Of course, 
an implementation is permitted to implement this work in any way consis- 
tent with the semantics. Thus, whenever feasible, this work is performed 
by the same processes executing the tasks participating in the multiway 
rendezvous, so the work is performed cooperatively. 

The multiway rendezvous, introduced in 1983[5], is a generalization of 
the Ada rendezvous [26] and also of the rendezvous in several other well- 
known concurrent languages such as CSP [16], DP [4], and SR [2], It has 
been shown that none of the parallel languages supporting the concept of 
a rendezvous also provides adequate support for the multiway rendezvous 
[6]. The multiway rendezvous can be viewed as an extension of a barrier[14] 
that supports cooperative multiway activities. 

The Adam language demonstrates the level of support for data paral- 
lelism provided by just two constructs: the diva procedure and the meet 
statement. Guy Steele, Jr. [25] lists several criteria a language should sat- 
isfy to adequately support data parallel programming, including the abil- 
ity to express the following: elementwise addition, conditional operators, 
broadcast, reduction, parallel prefix, and permutation. Using diva proce- 
dures and meet statements satisfies all these criteria, for vectors. 

Of course, vectors support a large class of important applications. They 


3 



can model successive values of sensors over a fixed time interval, where the 
resulting data can be scientific (such as the temperature of a valve in a 
spacecraft), social (such as population), or commercial (such as stock mar- 
ket statistics). Additional one-dimensional phenomena include computer 
programs, DNA, natural language texts, and manuscripts of music. For 
some applications, diva procedures can be used with more general data 
structures. For instance, a diva procedure can be written to copy one two- 
dimensional array into another, by treating a two-dimensional array as a 
vector of vectors. But when a diva procedure is used to operate on a two- 
dimensional array either the rows will be treated independently of each 
other or the columns will be treated independently of each other, so full 
two-dimensional information is not being considered. 

Creating a useful parallel programming concept is a balancing act among 
four primary goals: 

• providing a level of abstraction with simple rules, 

• supporting portability across parallel computers, 

• providing sufficient expressibility for useful applications, and 

• restricting the programmer to expressing high-level algorithms that 
permit generation of efficient code. 

Some programming concepts, such as GAMMA [3], provide more express- 
ibility than diva procedures. Some special-purpose programming concepts, 
such as primitives that satisfy single items in Steele's list, might be easier 
to translate into efficient parallel code than diva calls. Diva calls form a 
compromise between these two extremes, while providing a portable level 
of abstraction having simple rules. 

Although expressed in an extension of Ada, the multiway activities rep- 
resented by the diva procedure and the meet statement are presented as 
programming language concepts rather than just as constructs in a partic- 
ular language. These concepts can be adapted for use in a wide variety of 
languages, just as the multiway branch concept — inspired by Hoare’s case 
statement — has been widely adapted. 

The important issue of how to provide the illusion of shared memory on 
a distributed memory architecture has been left to other researchers [21]. 
The Adam language design effort has focused on orthogonal issues. 

The following sections describe applications conveniently supported in 
the Adam language. In addition to these applications, a diva call can be 
used to assign values to a vector, possibly using a computation based on 
corresponding values of vectors. 
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For simplicity, all complexity results in this report for calls on diva pro- 
cedures assume that the computation within a single activation of the pro- 
cedure takes constant time and that parameter passing for any parameter 
other than the vectors operated upon by a diva call (i.e., for any nondy- 
namic parameter, as defined in Chapter 2) takes constant time. These 
conditions are met by all applications described. 


1.3 Generalized Reductions 

Languages supporting data parallel programming provide convenient ways 
to perform reductions; i.e., certain single computations across all com- 
ponents of a vector, such as finding the sum or product or maximum or 
minimum of the component values. In addition, several such languages also 
permit the programmer to use any function in a reduction, as long as the 
function satisfies certain properties. All such languages require the function 
to be associative and some also require the function to be commutative. 

Any computation that can be performed using a reduction based on a 
programmer-defined function can be also be performed using a diva call. 
In addition, diva calls have the following advantages [8]: 

• The correctness of a diva procedure can be proven in a straightforward 
way, using the same kind of strong induction argument naturally used 
in verifying a recursive procedure. 

• Proving the associativity of a function can be very difficult, yet such 
a proof is essential for nontrivial programmer-defined functions. A 
separate proof of associativity is not required for diva procedures. 

• Diva procedures are provably more general than reduction functions: 
there exists a diva procedure whose corresponding combining function 
is not associative. 1 

• The semantics of a diva procedure are natural and easy for the pro- 
grammer to understand. The programmer has a simple sequential 
conceptual model for understanding these semantics: the model is 
based on the concepts of recursion and the nondeterministic divide. 
The latter delegates the choice of a division point in a vector used for 
recursive calls to the underlying implementation. 

Independent of and complementary to the development of the nondeter- 
rninistic divide are approaches that let the programmer specify an algorithm 

lr This follows from Example 2 of [9]. 
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for selecting the division point in a vector [20]. The Adam language demon- 
strates what can be accomplished without specifying such an algorithm. 

Diva calls can be used to perform a variety of computations on the 
sequences of values of vectors, such as: 

• computing the number of peaks in a sequence, where a “peak” is a 
term that is greater than both its predecessor and successor, 

• computing the position of the first term of a sequence of positive 
integers that is greater than a given value (or returning -1 if there is 
no such term), 

• computing the maximum sum among the nonempty slices of a se- 
quence of positive and negative integers, where a “slice” is a contigu- 
ous subsequence, 

• computing the number of runs in a sequence, where a “run” is a slice 
whose values are increasing, 

• computing the length of the longest plateau of a nondecreasing se- 
quence, where a “plateau” is a slice of equal values, 

• computing the length of the longest ascending slice of a sequence, 

• computing the value of a term of one sequence corresponding to the 
maximum of another sequence, 

• computing the length of the longest identical corresponding slice of 
two sequences, 

• computing the length of the longest ascending slice of a sequence such 
that the corresponding terms of another sequence are also ascending, 

• computing the largest increase among the pairs of adjacent terms of 
a sequence, 

• computing the largest increase from one term of a sequence to a later 
term of the sequence, where the location of the first such term is an 
in parameter of the diva procedure, 

• computing the largest increase from one term of a sequence to a later 
term of the sequence (and the two locations where such an increase 
first occurs), where the first such term varies over all terms of the 
sequence, 
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• computing the first record, in a sequence of records, whose fields have 
the most number of matches with the corresponding fields of a key, 2 
and 

• computing the length of the longest slice of one sequence whose terms 
are greater than the corresponding terms of another sequence (and 
the location where a slice of this length first occurs). 

The final application can be used to compare the readings of two sensors 
over time, analogous to computing the longest winning streak of one sports 
team over another. Quicksort is an example of a divide-and-conquer strat- 
egy that does not have a straightforward treatment using diva procedures, 
since the division of a vector by quicksort occurs only after some initial 
processing of the vector. 


1.4 Avoiding Certain Iterations 

Consider the problem of computing the first location of a component of 
an unsorted vector of length n whose value differs the least from a given 
component’s value, analogous to determining who in a group of n people has 
a height nearest a given person’s height. This problem can be solved using a 
diva call, so it belongs to the class described in the preceding section. Now 
suppose the given component value is to vary over all the component values, 
analogous to asking everyone in the group of people to determine whose 
height is closest to their own. Such an application can be programmed by 
iteration, using a loop containing a diva call of the kind, described in the 
preceding section, so that a total of n diva calls are made. 

But there is a simpler programming approach than such iteration, an 
approach that also provides guidance to the translator: place a diva call 
inside a meet statement and let the actual parameter corresponding to 
the given component value have a different value for different members of 
the array of tasks. [10] An Adam language rule assures us that such use 
of a diva procedure is just as easy to understand as a use of the same 
diva procedure in which different members of the array of tasks use the 
same actual parameter value, even though the net effect can be much more 
powerful. In addition, the target Ada produced by the Adam translator 
for a ring of n processors permits the n 2 computations to be performed in 
time proportional to n, which is optimal. 

Many applications described in the preceding section can be parameter- 
ized this way. For example, for each term of a nondecreasing sequence one 

2 This application was suggested by Dana Richards of the U. of Virginia. 
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could compute the length of the longest plateau containing the given term. 
Here are additional examples: 

• for each component in a vector, find the location of the first compo- 
nent to the right that has a greater value, if there is such a location. 3 

• sorting an array, 

• performing a parallel prefix calculation, 

• calculating the three accelerations on each of n astronomical bodies 
due to the masses and locations of the other bodies, 

• letting each member of an array of n tasks send a different value to 
some other task in the array, and 

• given a set of data, calculating which single piece of data, if omit- 
ted from the set, would cause the resulting variance to become the 
smallest. 4 

The first three of these additional examples, together with the example 
involving plateau lengths, are illustrated in Appendix A. 


1.5 Loosely Synchronous Applications 

When the term multiway rendezvous was introduced [5], its usefulness 
for a particular class of algorithms was illustrated. The algorithms in this 
class proceed by iterating stages, where part of the work of each stage is 
distributed among several processes, and where the only synchronization 
and communication is for sharing results among all these processes once 
during each stage (or, in general, a fixed number of times during each 
stage). 

Loosely synchronous algorithms — a term used by Geoffrey Fox [13] 
— include the algorithms in this class. An example of such an algorithm is 
the straightforward parallel algorithm for solving the n body problem. The 
n body problem is that of finding the positions of n astronomical bodies at 
the end of a given time interval, given their initial positions, velocities, and 
masses, and assuming the only accelerations will be those due to mutual 

3 This problem was posed to us by David Nicol of the Institute for Computer Applica- 
tions in Science and Engineering (ICASE) at NASA Langley Research Center, who had 
earlier needed to perform the calculation. 

4 This problem was posed to us by J. Van Bowen of the U. of Richmond, whose 
statistics Ph.D. dissertation includes a study of the variance of a set of data when one 
piece of data is omitted. 
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gravitational attraction. The straightforward parallel algorithm iterates 
over subintervals of the desired time interval and associates a process with 
each of the n bodies. Process i computes the new location of body i during 
each subinterval, using the locations and masses of all other bodies. 

A few other examples of such algorithms, given in [5], include: 

• The parallel farthest-insertion heuristic for the Euclidean traveling 
salesman problem [24]. 

• The parallel Floyd algorithm for finding the shortest distance between 
each pair of nodes in a network [11], given the length of each edge in 
the network. 

• Parallel Jacobi iteration [19]. 

• The parallel Prim-Dijkstra algorithm for finding the minimum span- 
ning tree of a network [12]. 

One approach to implementing such algorithms is to activate and deacti- 
vate processes before and after each stage. Another approach is to activate 
each process just once and to let the processes engage in a multiway ren- 
dezvous at each stage [6]. Advantages to the latter approach are: 

• The number of process activations and terminations are greatly re- 
duced; such operations can require significant amounts of processor 
time. 

• Local variables are kept alive, resulting in less need for nonlocal vari- 
able accessing. 

• With adequate support, such as that provided by the Adam language, 
the programmer can think at a higher conceptual level, leading to 
programs that are easier to write, read, debug, modify, test, and 
verify. 

1.6 Examples of Adam Programs 

This section gives simple examples of Adam programs to illustrate the key 
concepts, as well as a brief illustration of how these programs can be used. 

As Nicklaus Wirth has observed: 

A successful language must grow out of clear ideas of design 
goals and of simultaneous attempts to define it in terms of ab- 
stract structures, and to implement it on a computer, or prefer- 
ably even on several computers. [27] 
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The design of the Adam language reflects insights gained from simultane- 
ously developing a translator for the language. The central purpose of the 
Adam translator has been to facilitate such insights. Thus the translator 
is basic research: a prototype rather than a production quality translator. 

The first example given to illustrate a programming language tradition- 
ally involves one of the standard problems in computer science, such as 
computing a factorial, since to present a practical program initially would 
swamp the reader with details of a particular technical problem. Here is a 
VAX/ VMS 5 terminal session that illustrates the use of the Adam translator 
in computing 5 factorial: 

$ ADAM/MACHINE=LOOP_CUBE FACT. 

$ ADA FACT. 

$ ACS LINK FACT 

•/,ACS-I-CL_LINKING, Invoking the VAX/VMS Linker 
$ TYPE FACT.DAT1 
5 5 
5 

$ ASSIGN FACT.DAT1 ADA$INPUT 
$ RUN FACT 
120.0 

The first command translates the file FACT. . ADAM, containing the Adam 
procedure FACT, into the equivalent Ada file FACT. . ADA, containing the Ada 
procedure FACT. The rest of the session uses the VMS Ada environment: 
FACT.. ADA is compiled and the result is linked, yielding FACT.EXE, which 
is run, producing the output. 

The Adam translator can translate an Adam program into code for 
three different kinds of target machines: IPSC2, L00P.CUBE, and RING. The 
user indicates the desired target machine by using the appropriate qualifier 
in the ADAM command. An explanation of these three target machines 
appears later in the chapter. The above example illustrates the form of 
data required for an Adam program. Preceding any data to be read by 
the Adam program must be two integers; these indicate the minimum and 
maximum number of processes desired in implementing a diva call. [For 
diva calls outside a multiway rendezvous, these data values are used to 
determine the number of nodes activated in the IPSC2 implementation and 
the number of tasks activated in the LOOP.CUBE implementation.] 

The program FACT. .ADAM can be written at least three ways: using 
a high-level diva call outside a multiway rendezvous and using either the 
meet statement or the multiway accept statement form of the multiway 

5 VAX and VMS are trademarks of Digital Equipment Corporation. 
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rendezvous. We now provide listings of these three programs. All three can 
be translated so the factorial is computed in parallel. The first program is 
the only one to use the third 5 in the sample data file, since it is the only one 
of the three Adam programs that explicitly reads any input. To illustrate 
how tasks participating in a multiway rendezvous can receive the common 
answer from a diva call, in the second and third versions of FACT.. ADAM 
presented here, these tasks print out their copy of the answer, resulting in 
five copies of 120 . 0 in the output. Altering the program to produce a single 
copy of the output is simple: the output statement would be embedded in 
an if statement that tests whether MY.I equals 1. 

The following diva procedure is used in all three programs: 

generic 

type RANGE.TYPE is range <>; 

type DYNAMIC.VECTOR is array (RANGE.TYPE) of FLOAT; 
diva procedure FIND.PRODUCT (A: in DYHAMICLVECTOR; PROD: out FLOAT) is 
— Assign to PROD the * reduction of A 
INITIAL.PROD, FINAL JPROD: FLOAT; 
begin — FIND.PRODUCT 
if A’ LENGTH * 1 then 

PROD A (A ’FIRST) ; 
else 

FIND.PRODUCT (A’lNITIAL, INITIAL.PROD); 

FIND.PRODUCT (A ’FINAL t FINAL.PROD); 

PROD := INITIAL.PROD * FINAL.PROD; 
end if ; 

end FIND.PRODUCT; 

The Adam extensions to Ada used in the first version of FACT.. ADAM 
are a generic diva procedure, a diva procedure instantiation, and a call on 
an instantiated diva procedure. 

with FLOAT.TEXT.IO ; use FLOAT. TEXT.IO ; 
procedure FACT is 
N: INTEGER; 

— Place the declaration of diva procedure FIND.PRODUCT here 

begin — FACT 
GET (N); 
declare 

subtype SUBRANGE is INTEGER range 1..N; 
type VECTOR is array (SUBRANGE) of FLOAT; 

diva procedure USE.PRODUCT is new FIND.PRODUCT (SUBRANGE , VECTOR); 
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X: VECTOR; 

ANSWER : FLOAT; 
begin 

for I in SUBRANGE loop 
GET (X(I)); 
end loop; 

USE.PRODUCT (X , ANSWER) ; 

PUT (ANSWER, 10, 1, 0); NEW.LINE; 
end; 

end FACT ; 

The Adam extensions to Ada used in the second version of FACT_ . ADAM 
include a generic diva procedure, a diva procedure instantiation within the 
private part of a task type specification, and a task index declaration. The 
program also includes a meet statement containing a call on an instantiated 
diva procedure that uses hyphen notation to create a virtual vector using 
a local variable of the task type for the array of tasks. 

with FL0AT.TEXT.I0; uae FLOAT JTEXT.IO ; 
procedure FACT is 
PROD: FLOAT; 

N: constant INTEGER :* 5; 

subtype SUBRANGE is INTEGER range 1..N; 

type VECTOR is array (SUBRANGE) of FLOAT; 

— Place the declaration of diva procedure FIND.PRODUCT here. 

procedure PERFORM. COMPUTATION is 

task type WORKER.TYPE is 
private 

diva procedure USE.PRODUCT is new FIND.PRODUCT (SUBRANGE, VECTOR); 
end WORKER.TYPE; 

WORKER: array [MY. I: SUBRANGE] of WORKER.TYPE ; 

task body WORKER.TYPE is 

MY. VALUE: FLOAT:- FLOAT (MY.I ) ; 

MY.RESULT: FLOAT; 
begin — WORKER.TYPE 
meet 

USE.PRODUCT (WORKER [-] .MY. VALUE, MY.RESULT); 
end meet; 

PUT (MY.RESULT, 10, 1, 0); 
end WORKER.TYPE; 
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begin — PERFORM. COMPUTATION 

null; — Activate the array of workers, 
end PERFORM.COMPUTATION; 

begin — FACT 

PERFORM.COMPUTATION ; 
end FACT; 

The Adam extensions to Ada used in the final version of FACT_.ADAM 
include a generic diva procedure, a multiway accept entry declaration, a 
diva procedure instantiation within the private part of a task specification, a 
task index declaration, and a multiway accept entry call. The program also 
includes a multiway accept statement containing a call on an instantiated 
diva procedure that uses hyphen notation to create a virtual vector using 
a formal parameter of the multiway accept. 

with FLOAT.TEXT.IO ; use FLOAT.TEXT.IO; 
procedure FACT is 

N: constant INTEGER :■ 5; 

subtype SUBRANGE is INTEGER range 1..N; 

type VECTOR is array (SUBRANGE) of FLOAT; 

— Place the declaration of diva procedure FIND.PRODUCT here, 
task PARENT is 

entry P[MY_I: SUBRANGE] (X: in FLOAT; RESULT: out FLOAT); 
private 

diva procedure USE.PRODUCT is new FIND.PRODUCT (SUBRANGE. VECTOR) ; 
end PARENT; 

task body PARENT is 
PROD: FLOAT; 
task type CHILD.TYPE; 

CHILD: array [MY.I: SUBRANGE] of CHILD.TYPE; 
task body CHILD.TYPE is 
MY.RESULT : FLOAT; 

MY.VALUE: FLOAT :- FLOAT (MY.I) ; 

begin — CHILD.TYPE 

PARENT. P [MY. I] (MY.VALUE, MY .RESULT) ; 
end CHILD.TYPE; 

begin — PARENT 

accept P [MY_I : SUBRANGE] (X: in FLOAT; RESULT: out FLOAT) do 
USE.PRODUCT (P[-].X, PROD); 
end P; 

PUT (PROD, 10. 1, 0); 
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end PARENT; 


begin — FACT 

null; — Activate the PARENT task and thereby the array of CHILD tasks, 
end FACT; 


1.7 Available Target Codes 

Throughout this section, a multiway rendezvous means a meet statement 
or multiway accept statement, p and n denote positive integers such that 
p is the number of processes used in implementing a diva call, and n is the 
length of the vectors used in a diva call. To ensure sensible use of processes, 
n >= p must hold for each diva call; otherwise a run-time exception is 
raised. The value of p is determined by the data used with the Adam 
program, which begins with the minimum and maximum desired values for 
p ■ The programmer decides how the value of n is determined, whether by 
the data or by a constant or computation within the program. 

An Adam program can be translated into one of three kinds of Ada 
code, targeted for three kinds of parallel computers, with the choice made 
by a compile-time directive. For input data satisfying the requirements 
given in the next paragraph, the choice of target computer does not affect 
the logical behavior of the program, it only affects performance, such as 
efficiency and speed of execution. 

Here is a brief description of the three kinds of target Ada code: 

• The IPSC2 target code for the Intel iPSC/2 hypercube, for 
which p must be a power of 2. Adam programs most appropriate 
for the IPSC2 are those in which a diva call only appears outside a 
multiway rendezvous. The combining work required for such calls is 
performed in log time on the iPSC/2, which is optimal (to within a 
constant factor). In the target Ada this combining work is performed 
by calls on the iPSC/2 gopf system function; thus the programmer 
has the benefits of both the high-level of abstraction provided by diva 
procedures and an efficient implementation in terms of the gopf call. 

• The L0QP_CUBE target code for any parallel computer having 
an Ada compiler, such that the computer permits hyper- 
cube interconnections between nodes, places different mem- 
bers of an array of tasks on different nodes when there are 
sufficiently many nodes, and simultaneously executes Ada 
rendezvous between pairs of such node programs whenever 
logically possible. There are no additional requirements on 
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p and n. Adam programs most appropriate for the L00P_CUBE are 
those for which each diva call within a meet statement involves the 
same nondynamic (defined at the beginning of the next chapter) in 
values and the Adam program contains a pragma asserting this fact. 
Given p processors, the combining work required for any diva call in 
such a program is performed in log time, which is optimal (to within 
a constant factor). 

• The RING target code for any parallel computer having an 
Ada compiler, such that the computer permits bidirectional 
ring interconnections between nodes, places different mem- 
bers of an array of tasks on different nodes when there are 
sufficiently many nodes, and simultaneously executes Ada 
rendezvous between pairs of such node programs whenever 
logically possible. The value of p must be even and p = n 
must hold for any diva call within a meet statement. Adam 
programs most appropriate for the RING are those in which a diva 
call occurs only within a meet statement and for which each diva 
call within a meet statement involves different nondynamic in values, 
since (given p processors) such calls will be executed in linear time, 
which is optimal efficiency (to within a constant factor). 

The rest of this section provides additional details about these target 
parallel computers. The IPSC2 target code consists of both a host and a 
node Ada procedure. The host Ada procedure obtains the largest subcube 
of the iPSC/2 within the size bounds specified by the data. If the minimum 
number of nodes desired is not available, the exception 

ADAM_Z_MINIMUM_CUBE_SIZE_UNAVAILABLE 
is raised. If n < p, the exception 

ADAM_Z_DYNAMIC_VECTOR_LENGTH_SKALLER_THAN_MINIMUM_CUBE_SIZE 

is raised. The user can then resubmit the target code (without changing 
it), and if the latter exception has been raised, the user will want to re- 
consider the appropriate level of parallelism specified in the data. For any 
diva call outside a multiway rendezvous, the host procedure ships the node 
procedure to each node of the subcube so the work of such a diva call is 
performed in parallel, with the result returning to the host. If n = p, the 
nodes combine their individual values. If n > p, the nodes independently 
perform some of the work of the diva call, working on (within one of) the 
same number of components of each vector used in the diva call, before 
combining their partial results. Since the iPSC/2 Ada compiler does not 
translate an Ada rendezvous into internode communication, any use of a 
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multiway rendezvous is performed solely by the host program so there is 
no performance benefit for a diva call within a multiway rendezvous. 

Although the LG0P_CUBE and RING target Ada codes can be compiled 
and executed on any computer having an Ada compiler, they are designed 
for parallel computers that should become available at some future date. 
Currently the author knows of no parallel computer having an Ada com- 
piler that implements an Ada rendezvous as interprocessor communication 
so that large numbers of rendezvous can be executed simultaneously when 
this would be consistent with Ada semantics. Anticipating the ultimate 
availability of such a computer, the L00P_CUBE and RING target codes in- 
corporate restrictions on which members of a single-dimensional array W 
of tasks can call which other members, thereby simplifying the problem 
of mapping processes to processors, a problem an Ada system for such a 
computer would need to solve. 

For the LOOP_CUBE, Adam code for a diva call and for a multiway ren- 
dezvous is translated into target Ada that only permits W[i] to rendezvous 
with V[j] if the binary codes for i and j differ in a single bit position, 
viewing the range of W as going from 0 to p — 1. [But Adam places no ar- 
bitrary restriction on the programmer’s choice of the range of W.] If n > p, 
a diva call outside a multiway rendezvous is translated into Ada that uses 
loops to perform independent work within each task prior to the intertask 
communication for the call, so that in the case when p = 1, such a diva 
call is executed as an Ada loop. The rest of this paragraph assumes the 
kind of parallel computer described in the preceding paragraph. For the 
applications described in Section 1.3, the target Ada performs the work of a 
diva call within a meet statement in time proportional to n/p + log(p). For 
the applications described in Section 1.4, the target Ada performs the work 
of a diva call within a meet statement in time proportional to n 4- plog{p)\ 
when n — p these applications are better suited for translation to a ring. 

For the RING, Adam code for a diva call within a meet statement is 
translated into target Ada that only permits W [i] to rendezvous with W |j] 
if i and j differ by 1 modulo p, viewing the range of W as going from 0 to 
p — 1. Such a diva call is implemented so that, when the target code is 
executed on a suitable ring of processors, the number of rendezvous time 
steps required is p/2, where a rendezvous time step is the time required for 
executing a single Ada entry call (or several entry calls that can be executed 
simultaneously), and where the time for executing statements other than 
entry calls is ignored. 6 The target Ada performs the work of a diva call 
within a meet statement in time proportional to p (= n), on a suitable ring 

6 Scott Shauf, now at the U. of North Carolina at Chapel Hill, reduced the number of 
time steps from p to p/2. 
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of processors, as described above, for the applications described in both 
Section 1.3 and 1.4. For the latter class of applications, this is optimal, since 
p 2 computations are required for the given algorithms. For the applications 
in Section 1.3, the programmer should provide a pragma to ensure the target 
Ada achieves a smaller constant of proportionality; the pragma is explained 
in Section 3.2. 

1.8 Relationship Between Adam and Ada 

The Ada language has been criticized for being too elaborate [17]. Thus 
one should be very cautious in proposing an extension to Ada, especially if 
the extended features can interact with existing features of Ada to produce 
programs that are difficult to understand. The purpose of Adam is to 
make programs easier, rather than more difficult, to understand. Thus 
restrictions are placed on the types of interactions that can occur between 
the new and old features. For example, the multiway accept cannot be 
used to select options in an Ada select statement and calls on multiway 
accept entries cannot be used to select options in an Ada select statement. 
The Adam language, with these restrictions, fully supports the applications 
described in this report. 

Adam is a superset of Ada and thus the syntax and semantics of all 
Ada reserved words, comments, statement forms, etc., are preserved by 
the Adam translator. The only restrictions on the pure Ada used by an 
Adam programmer are the addition of the reserved words diva and meet 
and the fact that a user-defined identifier cannot have the prefix ADAM_Z 
and cannot have length greater than 40. The translator uses ADAM_Z as 
a prefix for identifiers inserted into the translated Ada form of the Adam 
program. Since the Ada programs generated by the Adam translator have 
comments beginning with — *♦* to explain the role of the Ada that has 
replaced extensions of Ada, the Adam programmer might wish to avoid 
using comments beginning with these characters so that the new comments 
are easier for a programmer to notice. Of course, there may be no need for 
a programmer to read an Ada program generated by the Adam translator. 

Since the introduction of Adam in 1987, the language has supported 
the automatic assignment of indexes to an array of tasks. Similar, but 
different, support will be provided in the next version of Ada ([1], 2. 4. 2.1). 
The approach used in Adam is illustrated below: 

task type WORKER.TYPE; 

WORKER: array [I : SUBSCRIPT.RANGE] of VORKERJTYPE; 

task body WORKER.TYPE is 

— the value of I can be used in these declarations 
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I can be used here 


begin 

— the value o t 

end WORKER.TYPE; 

The base type of such an indexed array must be a task type. 
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Chapter 2 

Rules for Diva 
Procedures 


This chapter presents the rules for declaring and instantiating diva proce- 
dures, which can be called from either outside or inside a multiway ren- 
dezvous. Rules for diva calls inside a multiway rendezvous are presented 
in Chapters 3 and 4 and rationales for the Adam constructs are given in 
Chapter 5. 

The formal syntax for a generic diva procedure will be given shortly; 
roughly speaking, it is a recursive procedure having a restrictive syntax 
that facilitates translation for parallel computers. A call on an instantiated 
diva procedure operates on one or more vectors having the same length. 
The formal parameters corresponding to these vectors are called dynamic 
parameters, since the recursive calls of the diva procedure use values of 
such parameters having progressively shorter lengths. The remaining items 
in the diva procedure formal parameter list are called nondynamic param- 
eters. The operation performed by the diva call can either assign a value 
to one or more nondynamic parameters, assign values to the components 
of one or more dynamic parameters, or both. For instance, the diva proce- 
dure FIND.PRODUCT of Section 1.6 assigns a value to one nondynamic 
parameter, the diva procedure FIND-LOC of Section 5.1 assigns values to 
two nondynamic parameters, and the diva procedure UPDATE at the end 
of Appendix A assigns values to the components of two dynamic parame- 
ters. 

The formal syntax of a generic diva procedure P is indicated in figures 
2.1 and 2.2. The notation { > denotes zero or one of the enclosed items, 
{ }* denotes zero or one or more of the enclosed items, and { >+ denotes 
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generic.diva.procedure.declaration 

GENERIC 

TYPE range.type.mark IS RANGE < > ; 

{ TYPE type_*ark IS ARRAY ( range.type.mark ) OF type.mark ; }+ 

DIVA PROCEDURE generic _diva.procedure.name 

( dynamic.parameter.declaration { ; dynamic.parameter.declarat ion }* 
{ ; non.dynamic.declarations } ) IS 

{ pure.ada.codel } 

BEGIN 

IF dynamic .parameter .name * LENGTH » 1 
THEN 

{ pure_ada_code2 } 

ELSE 

generic _diva.procedure.name 

( dynamic .parameter .name * INITIAL 

{ , dynamic .parameter .name ’ INITIAL }* 

{ , <identifier> >* ) ; 
generic _diva.procedure.name 

( dynamic .parameter .name * FINAL 
{ , dynamic .parameter. name * FINAL }* 

{ , <identifier> }* ) ; 

{ pure_ada_code3 } 

END IF ; 

{ RETURN ; } 

END generic_diva.procedure.name ; 

Figure 2.1: Syntax for Generic Diva Procedure Declaration. 


one or more of the enclosed items. An alternative is denoted by I . Each of 
the following nonterminals produce an identifier: generic_diva_procedure-name, 
range_type_mark, typejnark, and dynamic_parameter_name. All instances 
of range_type_mark within P must produce the same identifier. All in- 
stances of generic_diva_procedure_name within the diva procedure P must 
produce the identifier P. 

Nonterminals with the prefix pure_ada_code have the following addi- 
tional static semantic restrictions. The declaration block pure_ada_codel 
and the block pure_ada_code_3 cannot access a dynamic parameter. The 
only attribute of a dynamic parameter that can be accessed within the 
block pure_ada_code2 is the attribute FIRST and the use of this attribute 
is the only way a component value of a dynamic parameter can be accessed 
within the block. Access to nonlocals from within P is prohibited; thus 
objects used within P, including subprograms, must be declared within P. 
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dynamic_parameter_declaration 

::= dynamic _parameter_name { , dyna*ic_parameter_nante )■* : mode type_mark 
mode 

: : * IN I OUT I IN OUT 

non_dynam ic _decl ar at ions 

::= in_parameter_declaration 

{ ; in_parameter_declaration }* I 

out _or_ in_out_par ameter_declarat ion 

{ ; out _ or _in_ out ..parameter .declaration }* | 

in„parameter..declaration 

{ ; in_parameter_declaration }* 

; out_or_in_out_parameter_declaration 
{ ; out _ or _in_out_parame ter .declaration }* 


in_parameter_declaration 

: : * identif ier^list : IN type_mark I 

identif ier_list : IN range_type_mark 

out _ or _ in_out _paramet er_de c lar at ion 

identif ier_list : OUT type_mark I 

identif ier_list : OUT range.type.mark I 

identif ier.list : IN OUT type_mark I 


identif ier_list : IN OUT range_type_mark 
ident if ier_list 

::= < identified { , < identified }* 


Figure 2.2: Syntax for Diva Procedure Formal Parameters. 


The following objects cannot be declared within P: tasks, diva procedures, 
and diva instantiations. Two new attributes, INITIAL and FINAL, are 
defined by the implementation for each dynamic formal parameter in an 
activation of a diva procedure, access to these attributes is only permit- 
ted inside the two recursive calls on the generic diva procedure, and the 
attributes satisfy the three conditions in Figure 2.3, where A\ t A m are 
the dynamic parameters. 

Since the syntax rules don’t let the programmer specify the division 
point used for dividing a dynamic parameter A into ATNITIAL and 
A'FINAL , the implementation chooses the division point. This key con- 
cept of diva procedures is known as the nondeterministic divide. For 


21 



1. A{ equals INITIAL concatenated with AFFINAL, 

2. Both AiTN ITIAL and AFFINAL have nonempty ranges. 

3. The range of A^TN ITIAL equals the range of AjTN ITIAL and the 
range of AFFINAL equals the range of AFFINAL. 


Figure 2.3: Properties of Attributes INITIAL and FINAL , for each i and 
j between 1 and m. 


the nonrecursive call, the range of all dynamic parameters is specified by 
the first generic actual parameter in the instantiation. For the recursive 
calls, the underlying implementation supplies the constrained range, en- 
suring that conditions 1 through 3 of Figure 2.3 are satisfied. Condition 
3 means the same division point is used for multiple dynamic parameters, 
which is consistent with the fact that the syntax for a generic diva procedure 
requires all dynamic parameters to have the same range. 

As is true for Ada, the specification of a generic diva procedure can be 
separate from the declaration of the generic procedure body but the in- 
stantiation of the generic procedure cannot precede the declaration of the 
generic procedure body. The placement of a generic diva procedure instan- 
tiation depends on whether calls are made on the instantiated procedure 
outside or inside a multiway rendezvous: 

• Normal instantiation: Calls on such an instantiated diva proce- 
dure are permitted anywhere outside a multiway rendezvous that an 
Ada procedure call is permitted. Such an instantiation can be placed 
anywhere an Ada basic declarative item is permitted. 1 

• Private instantiation: Calls on such an instantiated diva proce- 
dure are only permitted within a meet statement or multiway accept 
statement. The instantiation is placed in a private part of a task (or 
task type) T. The declaration of the task is written as follows, for 
an instantiation I of a generic diva procedure G, where A1 and A2 
correspond to generic parameters: 

task T is 

... entries are declared here, i i there are entries 
private 

diva procedure I is new G(A1, A2) ; 

1 See Section 3.9 of [26] for the definition of such an item. 
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. . . additional diva instantiations can be placed here 
end T; 

The reserved word type can appear between task and T, when ap- 
propriate. If the diva call is in a meet statement within the body of 
T, then T must be a task type and there must be one and only one 
array declared to be of type T . 2 If the diva call is in a multiway accept 
statement within the body of T, there must be an array of tasks each 
component of which makes calls on the multiway accept. Note that in 
either case there is an array of tasks that participates in the multiway 
rendezvous. 


2 The syntax of Ada permits only one array to have a particular task type, if members 
of the array call other members of the array, since the array name itself must appear in 
the body of the task type. 
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Chapter 3 

Rules for the Meet 
Statement 


Although a more radical departure from Ada, the meet statement is gen- 
erally superior to the multiway accept because the rules are simpler, the 
notation is more concise, and yet the same expressive power is provided for 
the kinds of applications described in this report. Rationales for the rules 
in this chapter are given in Chapter 5. 


3.1 Meet Statements 

The formal syntax of the meet statement is indicated in Figure 3.1, where 
each of the nonterminals divaJnstantiation_name, array-name, and sim- 
ple_name produces an identifier. Square brackets are not used as metasym- 
bols in the formal syntax; they are lexical units within the Adam language. 
The meet statement can only appear inside the statement body of a task 
type T that is used in declaring a one-dimensional indexed array of worker 
tasks, W[l] , W[m] . 

The semantics of the meet statement are as follows: when any one of 
W[l], ..., W [m] reaches the meet statement it becomes suspended until all 
have reached the meet statement, whereupon the threads of control of W[l] , 
..., W[m] are combined into a single thread of control during the execution 
of the multiway _rendezvous_statements. 

Axioms for meet and end meet in the style of Hoare[15] are given in 
Figure 3.2 for programs satisfying the following property: if one of the 
workers W[l], ..., W[m] has write access to a nonlocal memory location 
outside meet statements, no other worker has read access to this memory 
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ueet. statement 

: MEET multiway.rendezvous.statements END MEET; 

Bult iway _r endezvous.st at ement s 

NULL ; I { diva.call.vithin.multiway .rendezvous }+ 

diva.call.within.multivay .rendezvous 

diva. instant iation.name ( actual.parameter.list ) ; 

actual.paramet er.l ist 

: :** { array .name , | simple, name [-] . simple .name , }+ 

{ { simple. name , }* simple. name } 

Figure 3.1; Syntax for the Meet Statement* 


location outside meet statements. This property is easy to satisfy for nearly 
all Adam programs solving the problems listed in Chapter 1* In Figure 3.2, 
P(i) and Q(i) are predicates with the free variable i. The range of i is the 
same as that of the array of tasks and any program variables appearing 
in the predicates must be visible from the point in the text of W[i] where 
the predicate appears. In addition, if an array X that is nonlocal to the 
task type for W appears within either of these predicates, the only subscript 
value that can be used with X in these predicates is i. Section 5.2 discusses 
the informal meaning of the two semantic axioms. 


3.2 Diva Procedure Calls 

A “private” instantiation is required for a diva call within a meet statement, 
as explained at the end of Chapter 2. 

Let W be an array of tasks with range SUBRANGE whose task type T con- 
tains a meet statement. Informally, the meet statement defines a meeting 
among the members of W, where the work of W[i] during the meeting is de- 
fined by the diva call within the code for W[i] . Although the code for each 
member of W is the same, it is possible for such a diva call to involve different 
nondynamic in values for different members of W and different nondynamic 
out values may be received by different members of V. When either or both 
occur, the effect of the diva call on the local variables o/W[z] and on the 
i ih component of nonlocal arrays is exactly the same as if all workers had 
used the nondynamic in values used by the particular worker W [i] and all 
workers had received the nondynamic out values received by the particu- 
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Axiom for meet 


{ P(i) > meet { V,P(t) } 


Axiom for end meet; 

{ V t O(i) } end meet; { Q(i) > 

Figure 3.2: Semantic Axioms. Here curly braces have the usual meaning 
for Hoare semantics. 


lar worker VDO. This rule keeps diva procedures relatively easy to write 
and understand yet enables them to have a powerful effect. The diva pro- 
cedures FIRST_RIGHT_GREATER and FIMD_PLATEAU_LENGTH in Appendix A 
illustrate this combination of simplicity and power. 

Let X be either the task index or a variable declared within T, and let 
Y be a nonlocal vector visible from the point of the diva call. Both W[-] .X 
and Y can be used as an actual parameter corresponding to a dynamic 
parameter; the former denotes a virtual vector whose range is SUBRANGE 
and whose value at the component is equal to W [ 2 ] ’s value of X. Such 
hyphen notation may only be used within diva calls. When X is used as an 
actual parameter corresponding to a nondynamic parameter, it denotes the 
value of X for that particular worker. 

Let I be an instantiation of a generic diva procedure G that has non- 
dynamic in parameters XI, ..., Xk and suppose calls on I appear inside 
meet statements. If the programmer knows that whenever such a call is 
executed, all values contributed by the participating tasks for the actual 
corresponding to XI are equal, all values corresponding to X2 are equal, ..., 
and all values corresponding to Xk are equal, the following pragma should 
be placed after the instantiation of I in the private part containing the 
instantiation 

pragma SAME_IN_VALUES (I); 

If the programmer wishes to indicate that pragma SAME_IN_VALUES applies 
to all instantiations of G in the program, this can be accomplished using 
the single pragma 
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pragma SAME_ I IL VALUES (G); 


inserted after the specification or body of G in the same declaration block 
as G. 

Pragma SAME_ I VALUES helps the translator generate efficient target 
code. The presence or absence of the pragma SAME_IN_VALUES affects only 
the performance of the target code, not its semantic correctness. However, 
since the effect on performance can be considerable, the presence or absence 
of such a pragma is reported during the execution of the ADAM command 
whenever the Adam program has a generic diva procedure G having a non- 
dynamic in parameter such that some instantiation of G is called from 
within a meet statement. The second program in Appendix A illustrates 
this pragma. 
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Chapter 4 

Rules for the Multiway 
Accept 


Although the multiway accept is a more straightforward extension of Ada 
than the meet statement, the rules for the multiway accept are more com- 
plex. The rationales for rules in this chapter are given in Chapter 5. 


4.1 The Multiway Accept 

The syntax for the multiway accept statement is indicated in Figure 4.1, 
where curly braces and the nonterminals multiway -rendezvous-statements 
and mode are explained in Chapter 2 and Figure 3.1. The remaining non- 
terminals in Figure 4.1 each produce an identifier. Square brackets are not 
used as metasymbols in the formal syntax, since they occur as lexical units 
within Adam. 

A multiway accept statement can appear only within a task body or 
task type body. For a given multiway accept entryJamily_name within a 
given scope, there must be at most one multiway accept statement, and 
if one exists, there must be one and only one array of tasks that make 
calls on the multiway accept entry family. Moreover, the multiway ac- 
cept statement cannot be contained within the tasks of this array, the dis- 
crete_range-type_name for the entry family must be the same as that used 
in declaring the array of tasks, and the task index variable must be the 
only expression used by a member of the task array in determining which 
member of the entry family to call. 

For a multiway accept entry family E, let SUBSCRIPT_RANGE be the dis- 
crete_range_type_name, whose range is 1 . . M. Also let T be the task con- 
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aultiway.accept.statement 

ACCEPT entry.faaily.name [ entry.lamily.index.declaration ] 

{ ( par aae t er.specif icat ion { ; parameter. spec if ication }* ) 
{ DO mult ivay .rendezvous. statements END { entry f ami l y_n am e 
ACCEPT entry .family.name [ entry.family.index.declaration ] 

{ ( parameter. specif icat ion { ; parameter .spec if ication >* ) 

entry, family, index.declarat ion 

: :■ entry. family. index. variable ; discrete.range.type.name 

parameter .spec if ication 

simple. name { , simple.name >* : mode type.mark 


Figure 4.1: Syntax for the Multiway Accept Statement. 


taining the multiway accept statement S that uses E and let W be the array 
of tasks indexed by SUBSCRIPT.RANGE that make calls on the entries in the 
family E. The preceding paragraph implies that calls must be made on the 
entries E[l], ..., E[M] by the tasks V[l], ..., V[Af], respectively, and that 
no other tasks can make calls on these entries. When each member of the 
family E has been called and task T has reached the statement S, the mul- 
tiway -rendezvous-statements within S are executed by T, with all members 
of the array V suspended during the execution. After the execution of the 
multiway .rendezvous-statements all M + 1 tasks resume their execution in 
parallel. 

To consider the parameter passing that supports the execution of S, let 
X be a simple_name used in the parameter j3pecification. An instance of 
X exists for each * in the range 1. .M. If the mode of X is in or in out, 
the value of the i ifl instance of X at the beginning of execution of multi- 
way -rendezvous-statements is the value of the corresponding actual param- 
eter in the entry call made by W[i] . If the mode of X is out or in out, the 
value of X at the end of execution of multiway .rendezvous-statements is the 
value received by the corresponding actual parameter of W [i] . 

The underlying implementation need only be consistent with the above 
semantics: the ordering of suspension of tasks is nondeterministic and the 
ordering of unsuspension of tasks is nondeterministic. As indicated in Fig- 
ure 4.1, a multiway accept need not contain multiway _rendezvous_statements } 
just as an Ada accept need not have a statement part. Such a multiway 
accept has the same semantics as a multiway accept containing just a null 
statement. 

No Ada accept can use a multiway accept entry family name and mul- 



tiway accepts cannot be used to select options in an Ada select statement. 


4.2 Syntax for a Multiway Accept Entry Dec- 
laration 

An entry family used with a multiway accept must be declared with explicit 
use of the index for the family as in 

entry E[I: SUBSCRIPT_RAHGE] (X: in Tl; Y: out T2) ; 

The use of the square brackets indicates these entries are multiway accept 
entries, rather than Ada accept entries. Like Ada entries, the use of a 
multiway accept entry family in the multiway accept statement must have 
exactly the same form as in the declaration; this includes the choice of 
identifiers and the choice of omitting or not omitting an explicit occurence 
of in. In addition, the identifier used in declaring the index of the entry 
family must be the same as the identifier used in declaring the index of the 
array of tasks that call the multiway accept and this must be the same as 
the identifier used as the index in making a call on the multiway accept 
entry. 


4.3 Syntax for a Multiway Accept Entry Call 

A task U[I] calls the multiway accept entry E[I] of task T using the nota- 

tion 

T.ECI] (...); 

where I is the task index identifier declared for the array W and where . . . 
represents the actual parameter list. Each actual parameter must be a local 
variable of the task type for W. 

Multiway accept entry calls cannot be used to select options in an Ada 
select statement. 


4.4 Diva Procedure Calls 

A “private” instantiation is required for a diva call within a multiway accept 
statement, as explained at the end of Chapter 2. 

Diva calls are used for operating on nonlocal vectors and on the vector 
of formal parameters within a multiway accept statement. (Diva calls may 
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also be used within a meet statement, as explained in Chapter 3, and outside 
a multiway rendezvous, as explained in Chapter 2.) 

The notation for accessing actual parameters within diva calls of a mul- 
tiway accept statement will be illustrated for the multiway accept: 

accept E[I: SUBSCRIPT_RANGE] (X: <model> Tl; Y: <mode2> T2) do 
raultiway_rendezvous_statements 

end E; 

The notation E[-] .X and E[-] . Y can be used as an actual parameter cor- 
responding to a dynamic parameter to refer to a virtual vector whose range 
is SUBSCRIPT_RAHGE and whose component values are the values of the 
relevant formal parameters. Thus, whereas within a diva call of a meet 
statement the use of the notation 

IDENTIFIER1 [-] . IDENTIFIER2 

refers to a virtual vector of local variables , this same notation inside a 
multiway accept statement block refers to a virtual vector of multiway 
accept parameter values. 

The actual parameter corresponding to a formal parameter of the diva 
procedure can refer to a variable declared prior to the multiway accept 
statement. However, if the formal parameter is a dynamic parameter, the 
following rule applies: the declaration of the variable used as the actual 
parameter must be visible at the multiway accept entry calls. 
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Chapter 5 

Rationales for Adam 
Constructs 


Three principles motivate many of the Adam design decisions: 

1. Provide a high level of abstraction. 

2. Permit a decentralized implementation whenever feasible. 

3. Don’t ask a programmer to make a choice if the choice 
doesn’t matter. 

By a high level of abstraction we mean that the focus of programming 
should be on what computation is desired, with the translator having the 
responsibility of deciding how to implement the desired synchronization 
and communication. 

The second principle is referred to in the rest of this report as “the 
decentralized implementation strategy” . Given a suitable computer, much 
of the work of a multiway rendezvous and of a diva call within it can be 
performed by the members of the array of tasks that participate in the 
multiway rendezvous. There are various ways to carry out such a strategy. 
A diva call outside a multiway rendezvous can also be implemented using a 
decentralized strategy, by creating an array of tasks invisible to the Adam 
programmer. 

The third principle is to some extent a corollary of the first principle. 
There are two extremes in which a particular choice wouldn’t matter: sit- 
uations where any choice among the available options is equally valid and 
situations in which only a single choice is valid, due to constraints elsewhere 
in the program. 
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The first extreme is illustrated in sequential programs by a multiway 
branch statement. Any choice of order in selecting branches of a multi- 
way branch leads to the same logical result and, since the case statement 
doesn’t ask the programmer to make a choice, it separates concerns of ef- 
ficiency from concerns of logical correctness. This extreme underlies the 
desirability of supporting nondeterminism in programming languages, such 
as that studied by Hoare [18]. Adam supports this kind of nondeterminism 
by not asking a programmer to make a choice in such things as the order 
of combining within the computation of a diva call and the order in which 
required calls on a multiway accept are processed. 

The second extreme is illustrated in Adam by the fact that the pro- 
grammer uses hyphen notation rather than indicating the range of a virtual 
vector used by a diva call within a multiway rendezvous. The only valid 
choice of this range is the range of the tasks participating in the multiway 
rendezvous. 

Exceptions are made to the third principle when necessary to keep Adam 
compatible with Ada, For example, Ada requires that the choice of identi- 
fiers in an accept statement be the same as the choice in the corresponding 
entry declaration and the Adam language has a similar requirement. 

Rather than striving for maximal generality, the Adam language demon- 
strates how the multiway rendezvous, combined with a suitably restrictive 
procedure employing no explicit parallelism, can provide a simple level of 
abstraction yet support translation to target code appropriate for a range 
of parallel computers. There are certainly straightforward ways in which 
the Adam constructs can be generalized. 


5.1 Diva Procedures 

The decentralized implementation strategy distributes the work of each 
call on a diva procedure. Thus diva procedures facilitate a time-efficient 
implementation, yet permit the programmer to think at a high level of 
abstraction. 

When appropriate for the target machine, the target Ada code produced 
by the Adam translator uses the following facts: 

• Given sufficiently many processors, a diva procedure can be executed 
in time proportional to log(n ), where n is the length of the vectors 
used as input by the procedure. This can be accomplished by imple- 
menting the nondeterministic divide as a divide at the middle of a 
vector and letting multiple processors use a binary combining tree to 
share in the computation of the procedure. 
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• The nondeterministic divide can be implemented as a divide just be- 
fore the last component of a vector (or just after the first component) 
thereby yielding a sequential loop. Such a loop is typically more effi- 
cient than recursion for implementing a diva procedure on a sequential 
computer. Thus during a single use of a diva procedure, some of the 
recursive activations — such as those near the beginning of execution 
of the procedure — can be carried out in parallel and the rest can 
be implemented sequentially without the overhead of recursive calls. 
This facilitates an implementation in which processors do some of the 
work on the procedure independently and then combine their partial 
results. If the divide were defined to be a deterministic divide at the 
middle, an implementation using a sequential loop (without a stack) 
would not be possible, in general. 

• The nondeterministic divide need not be implemented the same way 
on different processors, even for a single diva call within a single par- 
allel computer. For example, consider a RING target machine having 
an even number p of processors. When the pragma SAME_IN_VALUES 
is not used, the target code produced by the Adam translator imple- 
ments the nondeterministic divide so the number of ways one vector 
of length p is decomposed into single components at the same time by 
the different processors is p/2. It is even possible to implement the 
nondeterministic divide so that — at the same time — each processor 
uses a different decomposition. 

The correctness of a well-written diva procedure can be proven in a 
straightforward way. We illustrate this using the diva procedure in Fig- 
ure 5.1. As explained in Chapter 2, the underlying implementation chooses 
A’INITIAL and A’FINAL, used in making the recursive calls, to be nonempty 
slices of A such that A is A’INITIAL concatenated with A’FINAL. The pro- 
grammer is responsible for ensuring the correctness of such a diva procedure 
regardless of how the implementation chooses to make such a nondetermin- 
istic divide. 

Such a proof of correctness, based on strong induction, can proceed as 
follows: First show that, when A has length 1, the diva procedure satis- 
fies the specification given in its comments. Then assume the length of A 
is greater than 1 and the diva procedure satisfies its specification for all 
smaller vectors than the length of A, so that 

INITIAL.MAX is assigned the maximum value of A’INITIAL, 
INITIAL_LOC is assigned the first location of the maximum of A’INITIAL, 
FINAL_MAX is assigned the maximum value of A’FINAL, and 
FINAL_L0C is assigned the first location of the maximum of A’FINAL. 
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generic 

type RANGE.TYPE is range <>; 

type DYNAMIC. VECTOR is array (RANGE.TYPE) of INTEGER; 
diva procedure FIND.LOC (A: in DYNAMIC. VECTOR; 

MAX: out INTEGER; 

LOC: out RANGE.TYPE) is 

— MAX is assigned the maximum value of A. 

— LOC is assigned the first location of the maximum of A. 
INITIAL.MAX, FINAL.MAX, 

INITIAL.LOC, FINAL.LOC: INTEGER; 
begin 

if A* LENGTH - 1 then 
MAX :« A (A> FIRST); 

LOC A* FIRST; 
else 

FIND.LOC (A* INITIAL, INITIAL.MAX, INITIAL.LOC) ; 

FIND.LOC (A'FINAL, FINAL.MAX, FINAL.LOC) ; 
if INITIAL.MAX >- FINAL.MAX then 
MAX INITIAL.MAX; 

LOC :» INITIAL.LOC; 
else 

MAX FINAL.MAX; 

LOC FINAL.LOC; 
end if; 
end if ; 
end FIND.LOC; 


Figure 5.1: Generic Diva Procedure to Find the First Location of the Max- 
imum of an Integer Valued Vector. 
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To complete the proof, simply show that the false branch of the if state- 
ment assigns the specified values to MAX and LOC. 

A diva procedure can abstract away issues irrelevant to the logical cor- 
rectness of the procedure in question. Such issues include whether a loop 
will be used for sequential implementation, whether parallelism will be used 
to implement the procedure, whether the target computer is MIMD or 
SIMD, whether processors will do some of the combining work indepen- 
dently before combining their partial results, and what technique will be 
used in combining partial results from different processors (a combining 
tree of processors, left or right shifts, pointer doubling, or other technique). 
The resulting high-level syntax results in code more portable and easier 
to read, write, and verify than approaches failing to abstract away such 
details. 

The syntax rules of a generic diva procedure P are compiler-enforceable. 
The requirement that subprograms used within P be declared within P 
permits a compiler to disallow additional recursive calls on P as a result 
of executing this Ada code. The requirement that a diva instantiation 
cannot appear within the declaration of a diva procedure simplifies the 
implementation (and we have not yet found important applications of such a 
hierarchical approach except for computing reductions of multidimensional 
arrays). 

The syntax of generic diva procedures requires that dynamic parameters 
be listed first, followed by nondynamic parameters of mode in, if any, 
followed by other nondynamic parameters, if any. These restrictions enforce 
a convention intended to make the language easier for programmers to use. 
For instance, since a diva call operates on vectors, listing such vectors first 
in the diva call places them in a prominent position. Since they require 
the programmer to remember additional rules, the simplicity provided by 
these restrictions is debatable, and they might be lifted in the future. Only 
additional experience can resolve such issues. (A similar approach was 
taken by Ada in requiring that basic declarations precede later declarations; 
experience with this restriction has led to eliminating the restriction in the 
next version of Ada.[l]) 

Although an instantiation of an Ada generic procedure can be either a 
basic or a later declarative item, a normal instantiation of a generic diva 
procedure must be a basic declarative item. This restriction allows the 
translator to insert (at the corresponding place in the target Ada code) 
items permitted as basic, but not as later, declarative items. This restric- 
tion and the fact that such an instantiation cannot precede the declaration 
of the generic procedure body imply that an Adam program must have 
more than a single declaration block. 

The private part of a task type specification is an extension of Ada 
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that provides information to a task of the task type. Like the private part 
of a package specification, information within the private part of a task 
type specification is not visible outside the task type itself. Placing diva 
procedure instantiations within a private part of a task type specification 
is natural since an instantiated diva procedure can be viewed as a private 
resource. In addition, the translator can insert (at the corresponding place 
in the target Ada code) entries to support the decentralized implementa- 
tion strategy, with assurance that type names will bind correctly to the 
appropriate meanings. 


5.2 Meet Statements 

Notice that, placed in the code for the task type of an array of workers, the 
lines 

meet 

null; 

end meet; 

behave as a barrier [14], ensuring all workers synchronize before performing 
further work. 

Informally, the first semantic axiom in Figure 3.2 states that if P(i) 
holds prior to meet, then V,P(i) holds immediately after meet in the pro- 
gram text. This axiom conveys in a formal way the informal notion that 
no worker can get beyond meet until it and all other workers in the array 
have arrived at meet. Informally, the second semantic axiom states that if 
V,Q(i) holds before end meet, then Q{i) holds immediately afterwards in 
the program text. This axiom is based on the restriction required by these 
axioms, that if one of the workers has write access to a nonlocal memory 
location outside meet statements, no other worker has read access to this 
memory location outside meet statements. The reason the full strength of 
VjQ(i) cannot be asserted in the program text immediately after end meet 
is because this could create a race condition: for any t'i, worker i\ could 
modify the truth value of Q(ii), such as by executing a statement that 
assigns a value to the ii ih component of a nonlocal array. 

To illustrate the use of these semantic axioms, consider the second ver- 
sion of FACT_. ADAM in Section 1.6. In this example, n = 5 and P(i) can be 
the predicate 

WORKER [i] >s MY_ VALUE = i 
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and Q(i) can be the predicate 

WORKER [ i ] *s MY.RESULT = Yli<n * 
where Y\ denotes a product. 

The decentralized implementation strategy lets the work of a meet state- 
ment be performed by the members of the array of tasks whose task type 
contains the meet statement. 

The Adam translator relies exclusively on the pragma SAME_IN_VALUES 
for the information it provides. While it is conceivable that a compiler could 
extract this information for the applications described in this report, such 
information cannot be extracted for all Adam programs. For instance, input 
data could be used in the task type of an array of workers to determine the 
value to assign to a local variable used as an actual parameter corresponding 
to a nondynamic in parameter in a diva call within a meet statement. 


5.3 Square Bracket Notation 

Square brackets are used in the Adam language as a consistent notational 
device that 

• Avoids the use of reserved words, but makes clear an extension to Ada 
is being used. The extensions to Ada, except for meet statements and 
diva procedure declarations, instantiations, and calls, are: 

— multiway accept entry declarations 

— multiway accept entry calls 

— multiway accept statements 

— indexed task array declarations 

No new reserved words are used in these extensions. Instead square 
brackets indicate the difference between Adam and Ada. 

• Suggests powerful constructs are being used. For example, the Ada 
code needed to ensure that the members of an array of n tasks gain 
automatic access to their index requires the time for executing at least 
0 (log(n)) rendezvous. 

Furthermore, if rounded parentheses were used in a multiway accept 
entry call, then for a task T the syntax T.E(I) would be ambiguous unless 
one looked at declarations appearing possibly far earlier in the program. 
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It could either mean to call the entry E of an Ada accept (with actual 
parameter I) or to call the parameterless member E( I) of a multiway accept 
statement. Wirth has recommended that the syntax for a programming 
language should be capable of recursive descent parsing with one-symbol 
lookahead, regardless of how parsing is actually accomplished. He argues 
that this syntax is easy for programmers to understand. 1 


5.4 Multiway Accepts 

The decentralized implementation strategy is the reason why a non-hyphened 
variable used as an actual parameter corresponding to a dynamic parame- 
ter in a diva call within a multiway accept must be visible at the multiway 
accept entry call. 

Requiring that only a single multiway accept appear in a task for each 
entry family and prohibiting its use within a select statement make it easy 
for the implementation to determine which entry calls are associated with 
which multiway accepts in support of the decentralized implementation 
strategy. 

In the Ada accept statement the entry accepted must have exactly the 
same form as the declaration of the entry. The same holds for the multiway 
accept in Adam for compatibility between the two languages. This requires 
that the index of an entry family appear in the declaration of the entry 
family. Restrictions on the use of identifiers (in declaring the indexes of 
an entry family, in declaring the array of tasks, and in making entry calls) 
ensure that each task in the array of tasks can only call the corresponding 
entry of the multiway accept family. These restrictions not only simplify 
the Adam translator but are consistent with the use of reasonable structure 
in an Adam program 

A dotted notation, or something similar, is needed to create a virtual 
vector using the formal parameters of a multiway accept. This facility 
is to be contrasted with a restriction in Section 4.1.3, Paragraph 17, of 
the Ada reference manual [26]. Such notation facilitates the decentralized 
implementation strategy. 


5.5 Comparison of Two Approaches 

The meet statement and the multiway accept statement provide two dif- 
ferent methods of supporting the multiway rendezvous within an Adam 

1 See page 164 of Wirth’s Turing award lecture [28] and page 29 of the reprinted 
version of [27]. 
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program. A conceptual difference is that the multiway accept is used with 
an array of tasks and a centralizing task, which can execute the multiway 
accept statement as just one of many of its activities, whereas the meet is 
used with just an array of tasks. 

Comparisons of programs like those mentioned in Chapter 1 (and the 
two listed in that chapter that use the multiway rendezvous) suggest that 
the meet statement leads to shorter and simpler programs. The rules of 
the meet statement are also less awkward than the rules of the multiway 
accept. Awkward rules for the multiway accept, for which there are no 
corresponding rules for the meet statement include: the identifier used in 
declaring the index of a multiway accept entry family must be the same 
as the identifier used in declaring the array of tasks that call the multiway 
accept and this must be the same as the identifier used as the index in 
making a call on the multiway accept, neither a multiway accept nor a 
multiway accept entry call can be used to select options in an Ada select 
statement and, when hyphen notation is not used to refer to a dynamic 
parameter in a diva call within a multiway accept, the variable used for 
this purpose must be visible at the multiway accept entry calls. 
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Appendix A 

Additional Examples 


The following examples are given here: 

• USE_FIRST_RIGHT_GREATER_ . ADAM, which computes, for each posi- 
tion in a vector, the first position to the right holding a greater value, 
if there is such a position, 

• USE_L00KUP_ . ADAM, which computes the position in a not-necessarily- 
sorted vector whose component equals a given key value, 

• USE_FIND_PLATEAU_LENGTH_ . ADAM, which computes, for each posi- 
tion in a vector, the number of contiguous positions having the same 
value, 

• SORT_ . ADAM, which sorts a vector, and 

• USE_PREFIX_ . ADAM, which computes a parallel prefix result, 

as well as a diva procedure, UPDATE, which assigns values to the components 
of two vectors. An Ada package PARALLEL_OUT is used (but not shown) that 
permits a task to build up an output buffer via calls on PRINT. The task 
can eventually execute a PRINTLINE call to print the bufFer, thus avoiding 
unreadable interleaving of output from members of an array of tasks. 

A.l USE_FIRST_RIGHT_GREATER_.ADAM 

This first example also illustrates what a VAX/VMS terminal session can 
look like. To see that that the diva procedure FIRST_RIGHT_GREATER sat- 
isfies the specifications in its comment block, use strong induction as il- 
lustrated in Section 5.4, and assume that the parameters GIVEH_LOC and 
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GIVEH.VALUE are two fixed values. The rule given in the second paragraph 
of Section 3.2 then assures us that the diva call within the meet state- 
ment will have the desired effect, even though different members of WORKER 
actually use different values for these two parameters. 

$ TYPE USE_FIRST_RIGHT,GREATER, . ADAM 
with INTEGER_TEXT,IG , TEXT,IO, PARALLEL.. OUT ; 
use INTEGER_TEXT,IO, TEXT,I0; 

procedure USE_FIRST,RIGHT_GREATER is 

N: INTEGER; 

type ANS.TYPE is record 
LOC , 

VALUE: INTEGER; 

FOUND: BOOLEAN; 
end record; 

generic 

type RANGE_TYPE is range <>; 

type DYNAMIC.VECTOR is array (RANGE.TYPE) of INTEGER; 
diva procedure FIRST,RIGHT,GREATER (A: in DYNAMIC, VECTOR; 

GIVEN.LOC: in INTEGER; 
GIVEN,VALUE : in INTEGER; 

ANS: out ANS,TYPE) is 

— ANS. FOUND is true if and only if A has a component to the 
right of A (GIVEN, LOC) greater than GIVEN_VALUE. 

— If ANS. FOUND is true, then: 

ANS. LOC is the location of the first value to the right of 
A (GIVEN, LOC) greater than GIVEN,VALUE and 
ANS. VALUE is A(ANS.LOC). 

L, R: ANS,TYPE; 
begin 

if A* LENGTH - 1 then 

if A'FIRST > GIVEN.LOC and then A(A , FIRST) > GIVEN,VALUE then 
ANS. LOC A* FIRST; 

ANS. VALUE :» A ( A’ FIRST) ; 

ANS. FOUND TRUE; 
else 

ANS. FOUND :■ FALSE; 
end if; 
else 

FIRST_RIGHT,GREATER (A' INITIAL, GIVEN,L0C, GIVEN,VALUE , L) ; 
FIRST,RIGHT_GREATER (A'FINAL, GIVEN,L0C, GIVEN,VALUE, R) ; 
if L. FOUND then 
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ANS :« L; 

elsif R. FOUND then 
ANS :« R; 
else 

ANS. FOUND :» FALSE; 
end if ; 
end if ; 

end FIRST.RIGHT.GREATER; 


begin — USE_FIRST.RIGHT.GREA TER 
GET (N); 

PUT ("The length of the vector is ") ; 

PUT (N, 1); NEW.LINE; 
declare 

subtype SUBRANGE is INTEGER range 1..N; 
type VECTOR is array (SUBRANGE) of INTEGER; 
diva procedure MY.FIRST.RIGHT.GREATER is 

new FIRST.RIGHT.GREATER (SUBRANGE, VECTOR); 

X: VECTOR; 

ANSWER: ANS.TYPE; 

procedure DO.FIRST.RIGHT.GREATER is 

task type WORKER_TYPE is 
private 

diva procedure MY.FIRST.RIGHT.GREATER is new 

FIRST.RIGHT.GREATER (SUBRANGE, VECTOR); 

end WORKER.TYPE; 

WORKER: array [I : SUBRANGE] of WORKER.TYPE ; 

task body WORKER.TYPE is 
MY.ANSWER: ANS.TYPE; 

MY_X : INTEGER; 

package PAR.QUT is new PARALLEL.OUT ; 
use PAR.OUT; 
begin 

MY_X := X(I) ; 
meet 

MY_FIRST_RIGHT_GREATER (X, I, HY_X, MY.ANSWER); 
end meet; 

if MY. ANSWER. FOUND then 

PRINT ("The answer for WORKER [") ; PRINT(I); 

PRINT ("] is WORKERC"); PRINT (MY.ANSWER. LOC) ; PRINT ("]") 
else 
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PRINT ("No worker to the right of WORKER [") ; PRINT(I); 

PRINT ("] has a greater value"); 
end if; 

PRINTLINE; 
end WORKER.TYPE; 

begin — DO_FIRST_RIGHT_GREATER 

null; — Activate the array of workers, 
end DO_FIRST_RIGHT .GREATER ; 

begin — declare block 
for I in SUBRANGE loop 
GET (X(I>) ; 
end loop; 

PUT.LINE ("The vector of values is:"); 
for I in SUBRANGE loop 
PUT (X(I), 1); NEW.LINE; 
end loop; 

DO_FIRST_RIGHT_GREATER ; 
end; — declare block 
end USE_FIRST_RIGHT_GREATER ; 

$ ADAM/MACHINE-RING USE_FIRST_RIGHT_GREATER_ . ADAM 

WARNING: Pragma SAME.IN.VALUES is not found for diva procedure 
FIRST.RIGHT.GREATER 

Thus any single occurrence of a diva call on an instantiation of this 
diva procedure, where the call occurs within a meet statement, 
is assumed NOT to be made with the same corresponding in values for 
all tasks participating in the call. If this pragma was omitted 
unintentionally, then the computation of each diva call on this diva 
procedure is likely to take more run-time than necessary. 


$ ADA USE.FIRST_RIGHT_GREATER_.ADA 
$ ACS LINK USE_FIRST_RIGHT_GREATER 

%ACS-I-CL_LINKING, Invoking the VMS Linker for VAX.VMS target 
$ ASSIGN USE_FIRST.RIGHT_GREATER.DAT1 ADA$INPUT 
$ RUN USE_FIRST_RIGHT_GREATER.EXE 
The length of the vector is 10 
The vector of values is: 

1 

2 

3 

4 

5 
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2 

9 
6 
5 
8 

No worker to the right of V0RKER[ 10] has a greater value 
The answer for WORKER [ 2] is WORKER [ 3] 

The answer for WORKER [ 4] is WORKER [ 5] 

The answer for WORKERt 6] is WORKERt 7] 

The answer for WORKERt 8] is WORKERt 10] 

The answer for WORKERt 9] is WORKERt 10] 

The answer for WORKERt 1] is WORKERt 2] 

The answer for WORKERt 3] is WORKERt 4] 

The answer for WORKERt 5] is WORKERt 7] 

No worker to the right of WORKERt 7] has a greater value 
$ ASSIGN USE_FIRST_RIGHT_GREATER. DAT2 ADA$INPUT 

7, DC L- 1- SUPERSEDE , previous value of ADA$INPUT has been superseded 
$ RUN USE_FIRST_RIGHT_GREATER.EXE 
The length of the vector is 10 
The vector of values is: 

5 
4 
3 
2 
1 

10 
9 
8 
7 

6 

No worker to the right of WORKERt 10] has a greater value 
The answer for WORKERt 2] is WORKERt 6] 

The answer for WORKERt 4] is WORKERt 6] 

No worker to the right of WORKERt 6] has a greater value 

No worker to the right of WORKERt 8] has a greater value 

No worker to the right of WORKERt 9] has a greater value 

The answer for WORKERt 1] is WORKERt 6] 

The answer for WORKERt 3] is WORKERt 6] 

The answer for WORKERt 5] is WORKERt 6] 

No worker to the right of WORKERt 7] has a greater value 
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A. 2 USE_LOOKUP_.ADAM 


The program USE.FIRST.RIGHT.GREATER. . ADAM does not use either of the 
pragmas 

pragma SAME.IN.VALUES (USE.FIRST.RIGHT.GREATER) ; 
or 

pragma SAME.IN.VALUES (FIRST.RIGHT.GREATER) ; 
since neither USE.FIRST.RIGHT.GREATER nor any instantiation of the generic 
diva procedure FIRST.RIGHT.GREATER is intended to be used with just a 
single value for GIVEN.LOC. The various WORKER tasks certainly do not use 
the same value in the diva call 

MY.FIRST.RIGHT.GREATER (X, I, MY.X, MY.ANSWER) ; 
for the actual parameter I corresponding to the parameter GIVEN.LOC (or 
even for the actual parameter MY_X corresponding to GIVEN.VALUE). 

The following simple Adam program illustrates a situation in which 
this pragma should be used. The generic diva procedure LOOKUP in this 
program returns the component value of the vector B corresponding to the 
first position in the vector A where a component value equals a given key, if 
there is such a component of A. Since the programmer knows the same key 
value will be used in any particular call on an instantiation of LOOKUP, the 
pragma SAME.IN.VALUES is used to help the translator generate efficient 
code for the diva call on MY.LOQKUP. 

with TEXT. 10, PARALLEL.OUT; 

UBe TEXT.IO; 
procedure USE.LOOKUP is 

package INTEGER. TEXT.IO is new TEXT.IO . INTEGER. IQ (INTEGER); 

use INTEGER.TEXT.IO ; 

N: INTEGER; 

type ANSWER.TYPE is record 

FOUND: BOOLEAN; 

VALUE: INTEGER; 

end record; 

generic 

type RANGE.TYPE is range <>; 

type DYNAMIC. VECTOR is array (RANGE.TYPE) of INTEGER; 

diva procedure LOOKUP (A, B: in DYNAMIC. VECTOR; 

KEY: in INTEGER; ANS: out ANSWER.TYPE) is 

— ANS. FOUND is assigned the value TRUE if and only if KEY equals the value 
of a component of A. 

— If ANS. FOUND then ANS. VALUE equals the component value of B 
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corresponding to the first such component value of A. 
L, R: ANSWERJTYPE; — results of left and right slices 

begin 

if A ’LENGTH - 1 then 

ANS. FOUND :« (A (A ’FIRST) - KEY); 

ANS. VALUE B( A’ FIRST); 
else 

LOOKUP (A’ INITIAL, B’ INITIAL, KEY, L) ; 

LOOKUP (A’ FINAL, B ’FINAL, KEY, R) ; 
if L. FOUND then 
ANS L; 
else 

ANS := R; 
end if; 
end if ; 
end LOOKUP; 

pragma SAME.IN.VALUES (LOOKUP) ; 


begin — USE.LOOKUP 
GET (N) ; 

PUT ("The length of the vector is ") ; 

PUT (N, 1); NEWSLINE; 
declare 

subtype SUBRANGE is INTEGER range 1..N; 
type VECTOR is array (SUBRANGE) of INTEGER; 

X, Y: VECTOR; 

KEY: INTEGER; 

procedure D0_L00KUP is 

task type VORKER_TYPE is 
private 

diva procedure MY.LOOKUP is new LOOKUP (SUBRANGE, VECTOR) 
end WORKER.TYPE; 

WORKER: array [HY.INDEX: SUBRANGE] of VORKER_TYPE; 

task body WORKER.TYPE is 
MY_ ANSWER: ANSWERJTYPE; 
package PAR. OUT is new PARALLEL. OUT ; 
use PAR. OUT ; 
begin 
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■eet 

MY.LOOKUP (X, Y, KEY, MY.ANSWER) ; 
end meet; 

if MY.ANSWER. FOUND then 

PRINT ("WORKERt"); PRINT (MY. INDEX) ; PRINT("] finds the answer' 1 ); 
PRINT (MY.ANSWER. VALUE); PRINTLINE; 
else 

PRINT (“WORKER [ M ) ; PRINT (MY.INDEX) ; PRINTO’] finds no answer"); 
PRINT.LINE; 
end if; 

end WORKER.TYPE; 
begin — DO.LOOKUP 

null; — Activate the array of workers, 
end DO.LOOKUP; 

begin 

for I in SUBRANGE loop 
GET (X(I)); GET (Y(I)); 
end loop; 

PUT.LINE ("The vectors of keys and values are:"); 
for I in SUBRANGE loop 

PUT (X(I), 1); PUT (Y(I)); NEW.LINE; 
end loop; 

GET (KEY); 

PUT ("The key to search for is ") ; 

PUT (KEY, 1); NEW.LINE; 

DO. LOOKUP ; 
end; 

end USE.LOOKUP ; 


A. 3 USE_FIND_PLATEAU_LENGTH_.ADAM 

The Adam program in this section computes, for each position in a vector, 
the number of contiguous positions having the same value. 

with INTEGER.TEXT.IO, TEXT.IO, P ARALLEL.OUT ; 
use INTEGER.TEXT.IO, TEXT.IO; 

procedure USE.FIND.PLATEAU. LENGTH is 


— Each worker finds out how nany workers contiguous to it have the 

— same value as the worker itself. 

— We use the phrase "the plateau of A containing A(GIVEN.LOC) " in our 
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— comments to mean: M the longest slice of A that both contains the 

— component of A with subscript GIVEN.LOC and has all component values 

— equal to A (GIVEN.LOC) M . 

[This problem appears in Gries t D. , The Science of Programming, 
Springer-Verlag , New York, 1981.] 


N : INTEGER; 


type ANS_TYPE is record 
PLATEAU.LENGTH , 

LENGTH , 

FIRST.COUNT, 

LAST.COUNT : INTEGER ; 

PLATEAU_FROM_START , 
PLATEAU.TO.END : BOOLEAN ; 

end record; 


generic 

type RANGE.TYPE is range <>; 

type DYNAMIC.VECTOR is array (RANGE.TYPE) of INTEGER; 
diva procedure FIND.PLATEAU.LENGTH (A: in DYNAMIC.VECTOR ; 

GIVEN.LOC: in RANGE.TYPE; 

GIVEN.VALUE: in INTEGER; 

ANS: in out ANS.TYPE) is 

— If GIVEN.LOC is in the subscript range of A and 

A (GIVEN_L0C) » GIVEN.VALUE 

— then: 

ANS. PLATEAU. LENGTH is the length of the plateau of A containing 
A (GIVEN.LOC) , 

ANS . PLATEAU_FRQM_START if and only if the plateau of A containing 
A (GIVEN_L0C) includes the first component value of A, and 
ANS .PLATEAU.TO.END if and only if the plateau of A containing 
A (GIVEN_L0C) includes the final component value of A, 

— otherwise: 

ANS.PLATEAUJLENGTH has the value 0, 

ANS . PLATEAU.FROM. START is FALSE, and 
ANS.PLATEAU_TO.END is FALSE. 

— ANS. LENGTH is the length of A. 

— ANS . FIRST.COUNT is the number of consecutive components of A, 

starting with the first component of A, whose value is GIVEN. VALUE. 

— ANS . LAST.COUNT is the number of consecutive components of A, 

ending with the last component of A, whose value is GIVEN.VALUE. 

L, R: ANS.TYPE; 
begin 
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if A> LENGTH « 1 then 
ANS. LENGTH 1; 
if A 1 FIRST - GIVEN.LOC then 
ANS . PLATEAU.LENGTH i; 

ANS. PLATEAU.FROM.START :» TRUE; 

ANS.PLATEAU_TO.END TRUE; 

ANS . FIRST.COUNT 1; 

ANS . LAST.COUNT 1; 
else 

ANS . PLATEAU.LENGTH 0; 

ANS . PLATEAU_FROM_START :« FALSE; 

ANS .PLATEAU_TO_END FALSE; 
if A ( A’ FIRST) - GIVEN, VALUE then 
ANS . FIRST.COUNT 1; 

ANS . LAST.COUNT ;» 1; 
else 

ANS. FIRST.COUNT 0; 

ANS . LAST.COUNT 0; 
end if; 
end if ; 
else 

FIND.PLATEAU. LENGTH (A* INITIAL, GIVEN.LOC, GIVEN. VALUE, L) ; 
FIND.PLATEAU.LENGTH (A* FINAL, GIVEN.LOC, GIVEN.VALUE, R) ; 
if L . PLATEAU. LENGTH > 0 then 
if L . PLATEAU.TO.END then 

ANS . PLATEAU.LENGTH L . PLATEAU.LENGTH + R.FIRST.COUNT ; 

else 

ANS. PLATEAU.LENGTH L . PLATEAU.LENGTH ; 
end if ; 

elsif R. PLATEAU.LENGTH > 0 then 
if R. PL ATEAU.FROM. START then 

ANS. PLATEAU.LENGTH :« L.LAST.COUNT + R. PLATEAU.LENGTH ; 
else 

ANS. PLATEAU.LENGTH R . PLATEAU.LENGTH ; 
end if ; 
else 

ANS. PLATEAU.LENGTH :» 0; 
end if ; 

ANS. LENGTH L. LENGTH + R. LENGTH; 

ANS . PLATEAU.FROM.START : - *L . PLATEAU.FROM.START or 

(L. LAST.COUNT - L . LENGTH and R. PLATEAU.FROM.START) ; 
AHS.PLATEAU_TO.END R. PLATEAU.TO.END or 

(R.FIRST.COUNT - R. LENGTH and L. PLATEAU.TO.END) ; 
if L. FIRST. COUNT - L. LENGTH then 

ANS . FIRST.COUNT L. LENGTH + R.FIRST.COUNT; 
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else 

ANS . FIRST.COUNT L. FIRST.COUNT; 
end if ; 

if R.LAST.COUNT - R. LENGTH then 

ANS . LAST_COUNT L.LAST.COUNT + R. LENGTH; 
else 

ANS . LAST_COUNT R.LAST.COUNT; 
end if ; 
end if ; 

end FIND.PLATEAU.LENGTH; 


begin — USE_FIND_PLATEAU_LENGTH 
GET (N); 

PUT ("The length of the vector is ") ; 

PUT (N, 1); NEV.LINE; 
declare 

subtype SUBRANGE is INTEGER range 1..N; 
type VECTOR is array (SUBRANGE) of INTEGER; 

X: VECTOR; 

ANSWER: ANS.TYPE; 

procedure DO_ FIND.PLATEAU.LENGTH is 

task type WORKER.TYPE is 
private 

diva procedure MY. FIND.PLATEAU.LENGTH is 
new FIND.PLATEAU.LENGTH (SUBRANGE, VECTOR); 
end WORKER.TYPE; 

WORKER: array [I: SUBRANGE] of WORKER.TYPE; 

task body WORKER.TYPE is 
MY.ANSWER: ANS.TYPE; 

X.I : INTEGER; 

package PAR.OUT is new PARALLEL.OUT; 
use PAR.OUT ; 
begin 

X.I := X(I); 
meet 

MY.FIND.PLATEAU.LENGTH (X, I, X.I, MY. ANSWER) ; 
end meet; 

PRINT ("The plateau for WORKER [ M ) ; PRINT(I) ; PRINT ("] has length M ); 
PRINT (MY.ANSWER. PLATEAU.LENGTH) ; PRINT.LINE; 
end WORKER.TYPE; 
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begin — DO_FIND_PLATEAU_ LENGTH 

null; — activate the array of workers 
end DO.FIND.PLATEAU.LENGTH; 

begin — declare block 
for I in SUBRANGE loop 
GET (X(I)) ; 
end loop; 

PUT.LINE (’'The vector is: M ); 
for I in SUBRANGE loop 
PUT (X(I), 1); NEW.LINE; 
end loop; 

DO.FIND.PLATEAU.LENGTH ; 
end; — declare block 
end USE.FIND.PLATEAU. LENGTH ; 


A. 4 SORT- ADAM 

Here is an Adam program to sort a vector: 

with INTEGER.TEXT.IO, TEXT.IO, PARALLEL.OUT; 
use INTEGER.TEXT.IQ , TEXT.IO; 

procedure SORT is 


Sorts a vector into ascending order in parallel. 


The vector is distributed across an array of vorkers so that each worker 
is assigned a corresponding component value. Two diva calls are used: 

1. A diva call counts, for each I, hov many occurences of component 
values less than WORKER [I] *s component value are in the vector plus 
hov many occurences of component values equal to WORKER [I] J s 
component value are to the left of or at WORKER [I] . The resulting 
count is assigned to a local variable MY.TARGET. 

2. MY.TARGET is the target address in the vector where WORKER [I] J s value 
should be sent. Another diva call carries out the communication. 


N: INTEGER; 
generic 

type RANGE.TYPE is range <>; 

type DYNAMIC^ VECTOR is array (RANGE.TYPE) of INTEGER; 
diva procedure COMPUTE.COUNT (A: in DYNAMIC. VECTOR; 
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GIVEN.LOC: in RANGE.TYPE; 

GIVEN. VALUE: in INTEGER; 

COUNT: out INTEGER) is 

— COUNT is assigned the number of components of A that are either smaller 

— than GIVEN.VALUE or are: equal to GIVEN.VALUE and to the left or at 

— GIVEN.LOC . 

L, R: INTEGER; — results of left and right slices 
begin 

if A ’LENGTH - 1 then 

if A (A ’FIRST) < GIVEN.VALUE or else 

(A (A ’FIRST) « GIVEN.VALUE and then A ’FIRST <» GIVEN.LOC) then 
COUNT 1; 
else 

COUNT 0; 
end if ; 
else 

COMPUTE. COUNT (A ’ INITIAL, GIVEN.LOC, GIVEN.VALUE, L) ; 

COMPUTE. COUNT (A ’FINAL, GIVEN.LOC, GIVEN.VALUE, R) ; 

COUNT := L + R; 
end if ; 

end COMPUTE.COUNT ; 


generic 

type RANGE. TYPE is range <>; 

type DYNAMIC.VECTOR is array (RANGE. TYPE) of INTEGER; 
diva procedure COMMUNICATE (A: in out DYNAMIC.VECTOR; 

GIVEN.LOC: in RANGE.TYPE; 
GIVEN.VALUE: in INTEGER) is 
— If A has a subscript equal to GIVEN.LOC, then 
-- this component of A receives the value GIVEN.VALUE. 
begin 

if A ’LENGTH = 1 then 

if A ’FIRST - GIVEN.LOC then 
A(A ’FIRST) GIVEN.VALUE; 
end if ; 
else 

COMMUNICATE (A ’INITIAL, GIVEN.LOC, GIVEN.VALUE); 
COMMUNICATE (A ’FINAL, GIVEN.LOC, GIVEN.VALUE); 
end if ; 

end COMMUNICATE; 


begin — SORT 
GET (N) ; 

PUT ("The length of the vector is ") ; 
PUT (N, 1); NEV.LINE ; 
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declare 

subtype SUBRANGE is INTEGER range 1 . . N ; 
type VECTOR is array (SUBRANGE) of INTEGER; 

X: VECTOR; 

procedure DQ_SORT is 

task type VORKER_TYPE is 
private 

diva procedure MY .COMPUTE. COUNT is new COMPUTE.COUNT (SUBRANGE, VECTOR); 
diva procedure MY. COMMUNICATE is new COMMUNICATE (SUBRANGE, VECTOR); 
end WORKER.TYPE; 

WORKER: array [I: SUBRANGE] of WORKER.TYPE; 

task body WORKER.TYPE is 
COUNT: INTEGER; 

MY.TARGET : SUBRANGE; 

MY. VALUE: INTEGER; 

MY.NEW.VALUE: INTEGER; 
package PAR.OUT is new PARALLEL.OUT ; 
use PAR.OUT; 
begin 

MY. VALUE :« X(I); 

Beet 

MY .COMPUTE. COUNT (WORKER [-] .MY.VALUE, I f MY.VALUE, MY.TARGET); 
MY.COMMUNICATE (WORKER [-] .MY.NEW.VALUE, MY.TARGET, MY.VALUE); 
end meet; 

X(I) :« MY.NEW.VALUE; 
end WORKER.TYPE; 

begin — DO. SORT 

null; — Activate the array of workers, 
end DO.SORT; 

begin — declare block 
for I in SUBRANGE loop 
GET (X(I) ) ; 
end loop; 

PUT.LINE ("The vector of values before the sort is:"); 
for I in SUBRANGE loop 
PUT (X(I)); 
end loop; 

NEW.LINE; NEW.LINE; 

DO.SORT; 
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PUT.LINE ( M The vector of values after the sort is:"); 
for I in SUBRANGE loop 
PUT (X(I>); 
end loop; 

end; — declare block 
end SORT; 


A. 5 USE_PREFIX_. ADAM 

The next Adam program illustrates how a parallel prefix application can 
be programmed: 

with INTEGER.TEXT.IO , TEXT.IO, PARALLEL.OUT ; 
use INTEGER.TEXT.IO , TEXT.IO; 

procedure USE. PREFIX is 

N: INTEGER; 


generic 

type RANGE.TYPE is range <>; 

type DYNAMIC. VECTOR is array (RANGE.TYPE) of INTEGER; 
diva procedure PREFIX (A: in DYNAMIC. VECTOR ; 

GIVEN.LOC : in RANGE.TYPE; 

ANS; out INTEGER) is 

— ANS is assigned the result of applying F to A(A ’FIRST. .GIVEN.LOC) . 
L , R; INTEGER; 

BASE: INTEGER 0; 

function F (X, Y: in INTEGER) return INTEGER is 
begin — F 

return (X + Y) ; 
end F; 


begin — PREFIX 

if A 'LENGTH * 1 then 

if A 'FIRST <- GIVEN.LOC then 
ANS A (A 'FIRST); 
else 

ANS BASE; 
end if; 
else 

PREFIX (A'INITIAL, GIVEN.LOC, L) ; 
PREFIX (A 'FINAL, GIVEN.LOC, R) ; 
ANS F (L, R) ; 
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end if; 
end PREFIX; 

begin — USE.PREFIX 
GET (N) ; 

PUT ("The length of the vector is "); 

PUT Of, 1); NEW.LINE; 
declare 

subtype SUBRANGE is INTEGER range 1..N; 
type VECTOR is array (SUBRANGE) of INTEGER; 

X: VECTOR; 

ANSWER: INTEGER; 

procedure DO.PREFIX is 

task type WORKER.TYPE is 
private 

diva procedure MY ..PREFIX iB new PREFIX (SUBRANGE, VECTOR); 
end WORKER.TYPE; 

WORKER: array [I: SUBRANGE] of WORKER.TYPE; 

task body WORKERJTYPE is 
MY_ ANSWER: INTEGER; 
package PAR_0UT is new PARALLEL.. OUT ; 
use PAR.OUT; 
begin 
meet 

MY.PREFIX (X, I, MY.ANSWER); 
end meet; 

PRINT ("The answer received by W0RKER[ M ) ; PRINT(I) ; 

PRINT ("] is M ); PRINT (MY.ANSWER); PRINTLINE; 
end WORKER.TYPE ; 

begin — DO.PREFIX 

null; — Activate the array of workers, 
end DO.PREFIX; 

begin — declare block 
for I in SUBRANGE loop 
GET (X(I) ) ; 
end loop; 

PUT. LINE (’’The vector is: M ); 
for I in SUBRANGE loop 
PUT (X(I), 1); NEW.LINE ; 
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end loop; 

DO.PREFIX; 

end; — declare block 
end USE.PREFIX ; 


A. 6 UPDATE 

This section illustrates how a diva procedure can be used to assign values 
to components of two dynamic vectors. This diva procedure could be used 
in a program where A is the vector of health benefits paid to each worker 
in a company, B is the vector of total benefits paid to each worker, and 
FACTOR is a factor by which the health benefits will be increased. A similar 
diva procedure could be used to maintain some other desired relationship 
between the corresponding components of two or more vectors. 

diva procedure UPDATE (A: in out DYNAMIC. VECTOR; 

B: in out DYNAMIC. VECTOR; 

FACTOR: in FLOAT) is 

-- Each component of A is increased by the factor FACTOR. 

— Each component of B is increased by the amount of the increase in 
the corresponding component of A. 

AMOUNT.OF.INCREASE : FLOAT; 
begin 

if A 1 LENGTH * 1 then 

AMOUNT.OF.INCREASE A ( A' FIRST) * FACTOR; 

A (A’ FIRST) A (A’ FIRST) * (1.0 + FACTOR); 

B(A> FIRST) B(A’FIRST) + AMOUNT.OF.INCREASE; 
else 

UPDATE (A ’ INITIAL, B’ INITIAL, FACTOR); 

UPDATE (A’ FINAL, B ’FINAL , FACTOR); 
end if ; 
end UPDATE; 


63 




Appendix B 

Syntax Summary 


This appendix gives extended BNF for a generic diva procedure and for 
the meet and multiway accept constructs. The syntax for instantiations of 
generic diva procedures is the same as that for instantiating Ada generic 
procedures, except for the use of the private part of a task specification 
when appropriate. Other features of Adam, such as diva calls and one- 
dimensional indexed task declarations, are minor variations of Ada syntax, 
as explained earlier. 

Nonterminals in the grammar with the prefix pure_ada_code refer to 
pure Ada, with static semantic restrictions as explained in Chapter 2. Each 
of the following nonterminals produces an identifier: 


array _name 

diva_instantiation_name 
entry _f amily_name 
generic_diva_procedure_name 
simple_name 


discrete_range_type_name 
dynamic .par ameter_name 
entry_f amily_index_variable 
range _type_mark 
type.mark 


All instances of range_type_mark within the same declaration of a diva 
procedure must produce the same identifier. All instances of 
generic-diva_procedure_name within the diva procedure P must produce the 
identifier P. 

Square brackets are not used as metasymbols, since they occur as lexical 
units within Adam. The metasymbols used are as follows: { } denotes zero 
or one instances of the item contained within, { }* denotes zero, one, or 
more instances of the item contained within, { }+ denotes one or more 
instances of the item contained within, and I denotes an alternative. 


PAGE Cii 
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generic .diva.procedure .declaration 
GENERIC 

TYPE range.type.mark IS RANGE < > ; 

{ TYPE type .mark IS ARRAY ( range.type.mark ) OF type.mark ; }+ 

DIVA PROCEDURE generic.diva.procedure.name 

( dynamic .parameter .declaration { ; dynamic, parameter .declaration }* 

{ ; non_dynamic.de clarat ions } ) IS 

{ pure.ada.codel } 

BEGIN 

IF dynamic .parameter .name 9 LENGTH « 1 
THEN 

{ pure.ada_code2 } 

ELSE 

generic _diva.procedure.name 

( dynamic .parameter .name ’ INITIAL 

{ , dynamic .parameter. name * INITIAL }* 

{ , < identified }* ) ; 
generic .diva.procedure.name 

( dynamic. parameter. name 9 FINAL 

{ , dynamic. parameter. name ’ FINAL }* 

{ , < identified }* ) ; 

{ pure_ada_code3 } 

END IF ; 

{ RETURN ; > 

END generic.diva.procedure.name ; 
dynamic.parameter.declarat ion 

: :* dynamic.parameter.name { , dynamic.parame ter .name }* ; mode type. mark 
mode 

IN I OUT I IN OUT 

non.dynamic .declarations 

in.parameter. declaration 

{ ; in.parameter. declaration }* I 

out _or_ in. out .par ame t er.declar at ion 
{ ; out. or. in. out .parameter .declaration }* I 
in.parameter .declar at ion 
{ ; in.par ame ter. declar at ion }* 

; out .or. in. out .par ame ter .declaration 
{ ; out.or_in.out .parameter .declaration }* 

in.par ame t er.declar at ion 

: : - identif ier.list : IN type.mark I 

identif ier.list : IN range.type.mark 
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out.or.in.out.parameter.declaration 

:: m identif ier.list : OUT type.mark I 

identif ier.list : OUT range .type.mark I 

identif ier.list : IN OUT type.mark I 

identif ier.list : IN OUT range .type.mark 

identif ier.list 

< identified { , < identified }* 

generic.diva.Bpecif ication.declaration 
GENERIC 

TYPE type.mark IS RANGE < > ; 

{ TYPE type.mark IS ARRAY ( range -type.mark ) OF type_mark ; }+ 

DIVA PROCEDURE generic.diva.proce dure .name 

( dynamic.parameter.declaration { ; dynamic.parameter.declaration }* 
{ ; non.dynamic.declarations } ) ; 

generic.diva.body.declaration 

: : 33 DIVA PROCEDURE generic _diva.procedure.name 

( dynamic.parameter.declaration { ; dynamic.parameter.declaration }* 
{ ; non.dynamic.declarations } ) IS 

{ pure.ada.codel > 

BEGIN 

IF dynamic .parameter .name 9 LENGTH - 1 
THEN 

{ pure_ada_code2 } 

ELSE 

generic.diva.procedure.name 

( dynamic .parameter .name 9 INITIAL 
{ , dynamic .parameter .name * INITIAL 
{ , < identified }* ) ; 
generic.diva.procedure.name 

( dynamic .parameter. name 9 FINAL 

{ , dynamic .parameter .name 9 FINAL }* 

{ , <identifier> }* ) ; 

{ pure.ada_code3 } 

END IF ; 

{ RETURN ; > 

END generic.diva.procedure.name ; 
meet. statement 

: := MEET multiway.rendezvous.statements END MEET; 
mult iway.rendezvous.statements 
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NULL ; I { diva.call.within.multiway .rendezvous }+ 


diva. cal 1 .wit hin .mult iway.rendez vous 

: diva. ins t ant iation.name ( actual.parameter.list ) ; 

actual .parameter. list 

{ array.name , I simple .name [-] . simple. name , }+ 

{ { simple.name , >* simple.name } 

multiway .accept .statement 

ACCEPT entry.f amily.name [ entry. family.index.declar at ion ] 

{ ( parameter.specif ication { ; parameter .spec if ication }* ) > 

{ DO multiway.rendezvous.statements END { entry. family .name } } 

ACCEPT entry. family. name [ entry.f amily.index.declaration ] 

{ ( parameter.specif ication { ; parameter .spec if ication }* ) } 

entry .f amily. index.dec larat ion 

: :* entry.f am ily. index. variable : discrete.range_type.name 

parameter.specif ication 

simple.name { , simple.name : mode type.mark 
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